Agents (HOST)

Agents are programs that run on the target system, which can be a cloud scheduling and workflow orchestration solution, an Operating System, an application such as SAP, PeopleSoft, etc. They establish the connection between the Automation Engine and those target systems, start the execution of tasks and make both their monitoring and the corresponding reporting possible. Agents create log files that record what occurs.

As an administrator, you install, configure and maintain the Agents. These are your responsibilities:

1. Install the Agent.

2. Configure it.

3. Authenticate it.

4. Assign the Agent to the Clients it should have access to and define the rights it should have, see Assigning Clients to Agents.

5. Define User and User Group authorizations on the Agent. This grants Users and User Groups specific rights on the Agent. You do it in each client. For more information, see Defining the Authorizations Page.

An Agent logs in only once and, once connected, it remains always connected. The following duplicate login validation takes place:

• Upon installation, the Agent starts and tries to log in. If there is no Agent connection with the same name, the Automation Engine accepts the login attempt and stores the Agent name, port number, start time etc. It deletes this information when the particular Agent connection ends.

• Agents connect via TCP/IP to the communication process (CP) or Java communication process (JCP). The communication between CP/JCP and Agent is encrypted. It is the Agents that are in charge of keeping the connection alive, as well. When it is lost, they try to reconnect; the interval of reconnect attempts is configurable.

  For more information, see TLS/SSL Communication and Encryption and Non-TLS/SSL Communication and Encryption.

The procedure to install an Agent depends on the type of Automic Automation environment where you want to install them. This section provides a list of all possible installation scenarios and links to the areas in the documentation where the installation procedure is explained in detail.

On-Premises Agents

These topics explain how to manually install on-premises Agents:

• Installing the Agents Manually

• Agent Deployment - Script Examples

Containerized Agents

This topic explains how to build and run a Docker image hosting either a Windows, UNIX, or Java Agent in a container: Installing Containerized Agents.

Special Cases for Versions Earlier than v24

If you want to install Windows or Unix/Linux Agents with a version that is smaller than 24, you have the following options:

• Linux 64 Java Agents, see Installing the Agent for IBM AIX, Linux x64, and PowerPC 64 LE (Java).

• Agents for other UNIX platforms, see Installing the Agent for other UNIX Platforms .

• Windows 64 Java Agents, see Installing the Agent for Windows (Java).

Preconfigured Agents

You can add an Agent object in Client 0 and download a pre-configured Agent from Broadcom’s Marketplace. With this method, you do not have to configure its INI file, authenticate it, etc. The Agent is ready to use. See Adding and Downloading Agents in AWI.

Cloud Automation Agents

Broadcom provides multiple Agents that integrate Automic Automation with numerous cloud environments. The following topic provides a list of Automic Automation cloud integration Agents and links to their respective documentation: Cloud Integrations.

RA Agents

Broadcom provides Rapid Automation (RA) Agents that integrate and automate third-party applications. This topic outlines the basics of RA Agents and provides a link to the location in Broadcom’s Marketplace where you can access their documentation: Rapid Automation.

After installing an Agent, you configure it using its INI file. For detailed information about how to configure an Agent, click on the corresponding link at Agents INI Files. In addition, the UC_HOSTCHAR_DEFAULT - Host Characteristics variable lets you define default Agent settings.

You can also edit some of the Agent properties in Client 0 through the Automic Web Interface. For more information, see Configuring the Agent Properties.

See also:

• Configuration (INI) Files

• INI Files: Watch the Video

You can also define additional important parameters in AWI. The following topics explain them:

• Configuring the Traces for Agents in AWI

• Distributing Workload Among Agents

• Defining Advanced Agent Settings

Automic Automation or Automic SaaS systems can have thousands of Agents. As an administrator, you can limit the number of Agents to be displayed on the list in theAGENT_LIST_LIMIT key in the UC_SYSTEM_SETTINGS variable. The default is 5,000, the maximum is 20,000.

The number of Agents currently displayed is shown on the list toolbar. A plus next to the number indicates that there are more Agents available than those displayed. For example, if the AGENT_LIST_LIMIT has been set to "200" and more than 200 Agents have been assigned to the client, Agents (200+) is displayed on the toolbar.

The following columns are displayed by default:

• Status

Inactive agents are grayed out

• Name

• Maximum length: 32 characters

• Always in uppercase

• Do not use special characters when adding an agent to avoid problems in the target system

• Authenticated

  Authenticated agents are check marked

• Version

• TLS

  Agents that use TLS/SSL and establish a connection with the Java communication process (JCP) are check marked

  If an Agent is not check marked, it is a non-TLS/SSL Agent and establishes a connection with a communication process (CP) or connect through the CP port of the TLS Gateway, see TLS Gateway.

• Platform

Platform type of the agent

Note: This is not the operating system.

• Hardware

Information about the computer on which the agent is running such as the system type, number of processors, or processor type

• Software

Type of platform or operating system of the computer on which the agent is installed

• Software Version

• IP address

• Port no.

• Last logoff

• Number of clients

Number of user-defined clients in which the Agent has authorizations

• Linked

Whether the agent is linked to a ServiceManager or not

This depends on the settings made in the Service Manager section.

• Process ID

• ZDU Version

Either base (B) or target (T) version of the agent in connection with a ZDU, see System Upgrade - Zero Downtime Upgrade

The following columns are also available:

• Last check

  The time at which the status and other agent-related information was last checked

  Note: This applies only to non-TLS/SSL Agents. The keep-alive interval for TLS/SSL Agents is defined using the WEBSOCKET_TIMEOUT parameter, see UC_HOSTCHAR_DEFAULT - Host Characteristics.

• Communication Process

  Communication process connected with the agent

• Time difference

  Time difference between the time of the agent and the time of the Automation Engine

  This is helpful for interpreting job reports when the Automation Engine and the agent run on different hosts with different system times.

• MIB

  MIB information of the Agent that is used in connection with SNMP

  If available, the unique ID that identifies each monitored net element is displayed.

  For more information, see SNMP Support.

• Services

  Whether the Agent performs a special service:

  • MAIL - Agent used for e-mail connection

  • SQL - Database Agent used for resolving variable objects of type SQL

• Compression

  Compression method used as standard in File Transfers

• Authorizations

  Privileges granted to this Agent in the current Client:

  • R = Read, send data by a File Transfer

  • W = Write, receive data from a File Transfer

  • X = Execute

• Job res. max.

  Maximum Agent resources available for jobs

• FT. res. max.

  Maximum agent resources available for File Transfers

• Keep alive

  Interval in seconds in which the connection to the communication process is checked

  If the connection is lost, the agent tries to reconnect automatically to the first available communication process (CP), which could be a different agent to the previous one.

• Roles

  Administrators can define a role (free text) for the agent in its INI file. If so, it is displayed here.

• TLS Gateway

  Name of the TLS Gateway that is used when a non-TLS Agent is connected through the CP port of the TLS Gateway, see TLS Gateway.

• Net Area

  By default, this is the name of the Automation Engine system. For more information, see Net Areas in the Automation Engine.

  Important! This field is populated only for TLS Gateway instances that are used as a communication process (CP) and are assigned to a net area. It does not apply to the Agents nor to TLS Gateway instances acting as an Agent as only communication processes can be grouped in net areas.

Displaying the Agent Variables

To see the variables that have been defined for a particular Agent, select it and click the Details button on the toolbar. The Details pane displays the variables and the values that have been defined for the Agent .

Filtering the Content of the Agent List

It is possible to use different filters to customize the content of the Agents list. Click the Filter button on the toolbar to open the Filter pane. Agent Name, Status and IP Address are always displayed but you can add additional criteria.

Tip: You can share filtered lists with other users. You can also bookmark the filtered list to be able to access it quickly next time. For more information, see Bookmarking and Sharing Links.

As soon as an Agent starts, the system starts to collect and archive data. It logs and archives data until the Agent stops. It is not possible to turn off this function. The collected data is available from the Agent Executions list and from its report and it serves to analyze and troubleshoot errors. You access both from the Administration perspective, in the Agents list, by right-clicking the Agent and selecting Monitoring > Executions or Monitoring > Last Report.

Execution Data for Agents

Every row in the Executions list indicates when the Agent started and stopped, it describes its status and shows any available messages. The Agent execution data is available in Client 0 only. For more information, see Execution Data.

Agent Reports

Server and Agent reports include the following data:

• INI file content
• Start and end of the Server processes or Agents
• Connection between the Automation Engine, the Agents, and the Automic Web Interface
• Task processing and status
• Access administration messages in the context of the authorization system

To be able to access the Server and Agent reports you need the following rights:

• S - Executions (access to execution data) for objects of type SERV (servers) and HOST (Agents)
• P - Open Report (access to reports) for objects of type SERV (servers) and HOST (Agents)

For more information, see Understanding the Reports.

As soon as an object is executed, Automic Automation generates a runID for that execution. Each new execution generates its own runID. The same applies every time that an Agent starts, Automic Automation assigns it a runID.

To understand what happens on an Agent, to troubleshoot issues and find the reason why something went wrong, you use the reports and the Executions list, where detailed data about the configuration and activities that occurred in the Agent are recorded. Automic Automation's Gen AI simplifies this process substantially. This is how you call it and what you can expect from it:

1. Do one of the following

   • In any Client, in the Agents list select an Agent and right-click to select Monitoring > Analyze Last Execution.

   • In Client 0, open the Agent definition and click Analyze Last Execution in the toolbar on the Agent page.

2. The Automation AI Assistant panel opens and provides a summary and an analysis of what happened on the Agent during its last session. The Agent's last session is not the currently active one, but the previous, already ended one.

   Automic Automation's Gen AI crawls all available reports and logs and provides data about the Agent configuration (connection to the Automation Engine, host on which it runs, information on the used JRE version, etc.) and about all the activities that occurred on the Agent.

   If something went wrong, the Automation AI Assistant describes the issue and suggests solutions. It also provides a link to the execution and to its report.

3. You can start a conversation in the context of the execution in the Ask Automation AI Assistant field at the bottom of the pane. You can type any question you need to drill down into the reasons that caused the failure (if applicable), to request better error handling if you need more clarity as to why it happened, to ask for suggestions to better configure the underlying object, and so on. The Automation AI Assistant recognizes and remembers the context in which you ask your questions.

   The Automation AI Assistant responds in natural language. You can ask it to provide the answers in any format that you need (json, markup language, etc.) and you can have follow-up conversations with it in any language, not just in the language of your interface. The more precise that you word your question, the better the answer will be. You can ask your questions in any language.

4. To clear or exit the chat, click on the three dots to the right of the chat box and select Clear Chat / Exit Chat.

For more information, see:

• Analyzing Executions with Automic Automation's Gen AI

• Analyzing Reports with Automic Automation's Gen AI